Skip to content

Allow HTTPlug 2.0 #114

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 17 commits into from
Nov 6, 2018
Merged

Allow HTTPlug 2.0 #114

merged 17 commits into from
Nov 6, 2018

Conversation

Jean85
Copy link
Contributor

@Jean85 Jean85 commented Oct 31, 2018

Q A
Bug fix? no
New feature? yes
BC breaks? not sure yet
Deprecations? no
Related tickets -
Documentation not sure it's needed yet
License MIT

What's in this PR?

This PR (like php-http/discovery#115) is to test and allow HTTPlug 2 (and PSR-18)

Checklist

  • Updated CHANGELOG.md to describe BC breaks / deprecations | new feature | bugfix
  • Documentation pull request created (if not simply a bugfix)

To Do

  • Check and fix build failures

@GrahamCampbell
Copy link
Contributor

We should probably setup travis to test with 1.x and 2.x in each env.

@dbu
Copy link
Contributor

dbu commented Oct 31, 2018

have a composer --prefer-lowest build with php 7.3? or do we need more than that?

@Jean85
Copy link
Contributor Author

Jean85 commented Oct 31, 2018

Build is failing because HttpMethodsClient::sendRequest is missing the return type, so it's not PSR-18 and HTTPlug 2 compatible.

How should I tackle this? I see two roads:

  • aim to a new major release compatible just with HTTPlug 2, and leave the resolution of conflicting versions to Composer
  • try to work some magic and use some backward-compat trick to avoid any breaking changes

I would prefer the former, since I don't see how we could implement the latter; it would work only on PHP 7.2+ which has parameter widening, but we will be out of luck in PHP 7/7.1

@dbu
Copy link
Contributor

dbu commented Oct 31, 2018

👍 for a new major version that only works with httplug 2. will also keep the testing simpler ;-)

@sagikazarmark
Copy link
Member

New major version is OK, but that should go to a 2.x branch as we will probably have multiple, subsequent PRs.

@Jean85
Copy link
Contributor Author

Jean85 commented Oct 31, 2018

@sagikazarmark perfectly ok with that! If you can create the branch I'll re-target this PR and add (instead of replace) the branch alias in composer.json

@sagikazarmark
Copy link
Member

2.x branch is ready ;)

@Jean85 Jean85 changed the base branch from master to 2.x October 31, 2018 11:45
@Jean85
Copy link
Contributor Author

Jean85 commented Oct 31, 2018

Current build failure are pretty strange, because they manifest only when restricting the deps with external deps: https://travis-ci.org/php-http/client-common/builds/448853233

Same config without additional requires are green. I'll try to compare the installed deps to find the differences.

@Jean85
Copy link
Contributor Author

Jean85 commented Oct 31, 2018

I have different results between CI and local. The base problem seems to be in BatchExceptionSpec, because it's trying to test (with mocking or similar stuff) a class (BatchException) which is both final and an exception, so not doable.

What should I do? I'm not well versed with PHPSpec...

@Jean85 Jean85 changed the title [WIP] Allow HTTPlug 2.0 Allow HTTPlug 2.0 Oct 31, 2018
Copy link
Contributor Author

@Jean85 Jean85 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No longer WIP, please review!

I've added a few comments to clarify what I had to do to make the build green.

@@ -19,17 +16,15 @@ branches:
matrix:
fast_finish: true
include:
- php: 7.1
env: COMPOSER_FLAGS="--prefer-stable --prefer-lowest" DEPENDENCIES="doctrine/instantiator:^1.1"
- php: 7.0
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was previously on PHP 7.1 due to doctrine/istantiator 1.1, which is no longer required. I've added a conflict rule below.

- php: 7.0
- php: 7.1
- php: 7.2
env: COVERAGE=true TEST_COMMAND="composer test-ci" DEPENDENCIES="henrikbjorn/phpspec-code-coverage:^1.0"
- php: 7.2
env: COVERAGE=true TEST_COMMAND="composer test-ci" DEPENDENCIES="leanphp/phpspec-code-coverage"
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a maintained fork of the previous package, which is now abandoned.

@@ -44,9 +39,10 @@ matrix:
env: STABILITY="dev"

allow_failures:
# Latest dev is allowed to fail.
- php: 7.3
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not working for now, but the issue is on Travis' side. Will work as soon as they fix it.

"php-http/message-factory": "^1.0",
"php-http/message": "^1.6",
"symfony/options-resolver": "^2.6 || ^3.0 || ^4.0"
},
"require-dev": {
"phpspec/phpspec": "^2.5 || ^3.4 || ^4.2",
"phpspec/phpspec": "^3.4 || ^4.2",
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dropping 2.x which was needed only to run under PHP 5.x

composer.json Outdated
"guzzlehttp/psr7": "^1.4"
},
"conflict": {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Those are lower bounds to avoid issues in CI builds. Should not affect --prefer-lowest.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

--prefer-lowest will respect the conflict section. as will other packages, as discussed below. do we use the doctrine/instantiator or sebastian/comparator in our actual code, or only for tests? all things thests should be solved in require-dev rather than here, or we prevent installing this on some systems that are fine with those versions.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Both packages are needed by the test suite through PHPSpec/Prophecy; the dev deps tree should not have packages in common with the non-dev deps, so it should be fine. I preferred to use conflicts instead of requiring them explicitly because they are both indirect dependencies that could go away at any time.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the problem is that conflicts are also respected by applications using this package. meaning that if my project uses an older version of one of the libraries we mark as conflicting here will not be able to install this package because of the conflict.

conflict should only be used to mark versions of packages that may not be run together with this package. they should not be used to control what is installed for development. if this is all only about --prefer-lowest, i think we either need them in require-dev, or if you want to be more explicit, put them in the DEPENDENCIES of .travis.yml only for the lowest version build - that would be the most explicit way of doing it, imho.

composer.json Outdated
"guzzlehttp/psr7": "^1.4"
},
"conflict": {
"doctrine/instantiator": "<1.0.5",
"phpspec/prophecy": "<1.8",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does conflict interact with the global require ? Because it's only in conflict for the dev environment, does conflict-dev exist ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sadly conflict-dev does not exist, so we should keep the old behavior (minimum version in require dev), as the runtime library does not conflict with prophecy < 1.8. It's only the tests.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's possible to simulate conflict-dev by making a dummy package that has exactly one conflict, then require said package in require-dev.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good catch. i'd prefer requiring prohecy ^1.8 in require-dev over creating a dummy package.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ouch I didn't think of this issue! Maybe moving to require-dev is good enough?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes please set thoses packages into the require dev section instead of using conflict

@@ -11,16 +11,21 @@
}
],
"require": {
"php": "^5.4 || ^7.0",
"php-http/httplug": "^1.1",
"php": "^7.0",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why not go directly to 7.1? afaik 7.0 is EOL already.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because it's the same of PSR-18 and HTTPlug 2.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Im fine with 7.1. For psr18 it did not really matter. It was not using any php7.1 features.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as long as we agree that dropping 7.0 support is a minor change and we "just do it" if 7.0 becomes a pain for some reason, i am fine with allowing it for now ;-)

@Nyholm
Copy link
Member

Nyholm commented Nov 2, 2018

This PR require us to release a major version. Is this really what we want?

We could modify it to allow httplug 1 and 2. That would be an easier migration, right?

@sagikazarmark
Copy link
Member

We could modify it to allow httplug 1 and 2. That would be an easier migration, right?

Technically that could work. We should probably consider it.

@joelwurtz
Copy link
Member

Does not work since HttpMethodsClient is not final (so it's a BC break if we change the signature, exactly like the Guzzle package)

@Nyholm
Copy link
Member

Nyholm commented Nov 2, 2018 via email

@Jean85
Copy link
Contributor Author

Jean85 commented Nov 4, 2018

Yep, exactly, it's a BC. But users of this lib will be able to require both versions if they want to support both HTTPlug versions.

BTW, what do you want me to do regarding the lower bound for Prophecy and doctrine/instantiator?

@Jean85
Copy link
Contributor Author

Jean85 commented Nov 6, 2018

I've moved the conflicts to require-dev as per #114 (comment)

Copy link
Contributor

@dbu dbu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good to me, thanks!

i like that we use >= in the require-dev for the constraints, like this its clear its not regular dependencies.

@dbu dbu merged commit b7e032b into php-http:2.x Nov 6, 2018
@Jean85 Jean85 deleted the patch-1 branch November 6, 2018 11:40
@Jean85 Jean85 mentioned this pull request Nov 6, 2018
5 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants